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ABSTRACT 

Each member of the Larch family of formal specification languages has a component derived from a 
programming language and another component common to all programming languages. We call the former 
interface languages, and the latter the Larch Shared Language. 

This report presents version 1.0 of the Larch Shared Language. It begins with a brief introduction to the 
Larch Project and the Larch family of languages. The next chapter presents most of the features of the Larch 
Shared Language and briefly discusses how we expect these features to be used. It should be read before 
reading either of the remaining two chapters, which are a self-contained reference manual and a set of 
examples. 
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Context 

TJie Larch Family of languages 

-- The Larch Project is developing tools and techniques intended to aid in the productive use of 
formal specifications of systems containing computer programs. Many of its premises and goals are 
discussed in [Guttag, Horning, and Wing 82]. 

We view a system as consisting of a state and mechanisms for changing and extracting information 
from that state. We choose to define the information contained in the state without reference to 
either how that information was created or how it will be used. Our specifications consist of two 
parts. In one, we specify the properties of values that may appear in system states, and in the second, 
the program modules mat deal with those states. 

A major component of the Larch Project is a family of specification languages. Each Larch 
language has a component particular to a specific programming language and another component 
common to all programming languages. We call the former interface languages, and the latter the 
shared language. 

We use the interface languages to specify program modules. Specifications of the interface that 
one module presents to other modules often rely on notions specific to the programming language, 
e.g., its denotable values or its exception handling mechanisms. Each interface language deals with 
what can be observed about the behavior of programs written in a specific programming language. 
Its simplicity or complexity is a direct consequence of the simplicity or complexity of the observable 
state and state transformations of that programming language. 

The shared language is algebraic. It is used to specify abstractions that are independent of both 
the program state and the programming language. The operators defined by an algebraic specification 
appear in specifications written in the interface languages, and in reasoning about such specifications, 
but they are not directly available to users of programs. The role of shared language specifications 
is similar to that of abstract models in some other styles of specification. 

Some important aspects of the Larch family of specification languages are: 
Composability of specifications. We emphasize the incremental construction of specifications 
from other specifications. The importance of such mechanisms is discussed in [Burstall 
and Goguen 77]. Larch has mechanisms for building upon and decomposing 
specifications as well as for combining specifications. 
Emphasis on presentation. Reading specifications is an important activity. To assist in this 
process, we use composition mechanisms defined as operations on specifications, rather 
than on theories or models. 
Interactive and integrated with tools. The Larch languages are designed for interactive use. 
They are intended to facilitate the interactive construction and incremental checking of 
specifications. The decision to rely heavily on support tools has influenced our language 
design in many ways. 
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Semantic checking. It is all too easy to write specifications with suprising implications. We 
would like many such specifications to be detectably ill-formed. Extensive checking 
while specifications are being constructed is an important aspect of our #proach. Larch 
was designed to be used with a powerful theorem prover for semantic checking to 
supplement the syntactic checks commonly defined for specification languages. We 
have been influenced here by our experience with Affirm [Musser 80]. 

Programming language dependencies localized We feel that it is important to incorporate many 
programming-language-dependent features into our specification languages, but to 
isolate this aspect of specifications as much as possible. This prompted us to design a 
single shared language that could be incorporated into different interface languages in 
a uniform way. 

Shared language based on equations. The shared language has a simple semantic basis taken 
from algebra. Because of the emphasis on composability, checkability and interaction, 
however, it differs substantially from the "algebraic" specification languages we have 
used in the past 

Interface languages based on predicate calculus. Each interface language is based on assertions 
written in typed first-order predicate calculus with equality, and incorporates 
programming-language-speciffc features to deal with constructs such as side effects, 
exception handling, and iterators. Equality over terms is defined in the shared language; 
this provides the link between the two parts of a specification. 

Status and Plans 

We are still in the early phases of the Larch project In addition to the work described in this 
report, interface languages for CLU and Mesa have been designed [Wing 83] contains a detailed 
description of the semantics of the CLU interface language. The Mesa interface language has not 
been documented, but we have used it, in conjunction with the shared language, to specify the 
program level interface to the Cypress data base system. This is die largest specification we have 
attempted 

A primitive checker for the Shared Language has been implemented [Kownacki 83]. In addition 
to parsing specifications, this program checks various context sensitive constraints and provides 
mechanisms for "expanding" assumptions, importations, and inclusions. This checker is an interim 
tool. We designed our specification language in tandem with an editing and viewing tool. Many 
language design decisions were influenced by the presumption that specifications would be produced 
and read interactively using this tool. A first design is complete [Zachary 83], but implementation 
has yet to begin. 

We are in the process of implementing term rewriting software [Forgaard 83], [Lescanne 83] that 
we hope will provide much of the theorem-proving capability needed for analyzing specifications. 
The definition of the Larch Shared Language calls for a number of checks for which there can be 
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no effective procedure. We have what we believe are useful procedures, based on sufficient or 
necessary (but not both) conditions, for some of these checks, eg., consistency. We are working on 
procedures for the others, e.g., checking constrains clauses. This is a difficult task. Diagnostics present 
a particularly vexing problem: How should relatively complicated theorem-proving procedures report 
problems to users who are not familiar with either their internal structure or the theory underlying 
them? 

It is always difficult to evaluate a language that has not been extensively used. The Larch Shared 
Language is especially hard to evaluate because it has been designed for use in an environment that 
we have not yet built In addition to the specification of Cypress, we have written a number of small 
specifications. On the whole, we were pleased by the ease of constructing these specifications in 
Larch, and with the specifications themselves. While constructing them, we uncovered several errors 
by inspection; we are encouraged that most of these errors would have been detected automatically 
by the checks called for in the language definition. It will be some time, however, before we can 
draw any strong conclusions about the potential utility of Larch in software development 
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1. Simple Algebraic Specifications 

Most of die constructs in die Larch Shared Language are designed to assist in structuring 
specifications, for both reading and writing. The trait is our bask module of specification. Consider 
the following specification for tables that store values in indexed places: 
TableSpec: trait 

introduces 

new: -*■ Table 

add: Table, Index, Val -♦ Table 
#€#: Index, Table -* Bool 
eval: Table, Index -♦ Val 
isEmpty: Table -* Bool 
size: Table -* Card 
constrains new, add, €, eval, isEmpty, size so that 
for all [ ind, indl: Index, val: Val, /: Table ] 

eval(add(/, ind, val) , indl ) = if ind = indl then val else eval(/, indl) 

ind € new = false 

ind € add(/, indl, val) = (ind = indl) \ (ind € /) 

size(new) = 

size(add(/, ind, val)) = if ind € / then size(/) else sizeO) + 1 

isEmpty(/) = (size{/) = 0) 

This example is similar to a conventional algebraic specification in the style of [Guttag and 

Homing 80] and [Musser 80]. The part of the specification following introduces declares a set of 

operators (function identifiers), each with its signature (the sorts of its domain and range). These 

signatures are used to sort-check terms (expressions) in much the same way as function calls are 

type-checked in programming languages. The remainder of the specification constrains the operators 

by writing equations that relate sort-correct terms containing them. 

There are two things (aside from syntactic amenities) that distinguish this specification from a 

specification written in our earlier algebraic specification languages: 

A name, TableSpec, is associated with the trait itself. 

The axioms are preceded by a constrains list 

The name of a trait is logically unrelated to any of the names appearing within it In particular, 

we do not use sort identifiers to name units of specification. A trait need not correspond to a single 

"abstract data type," and often does not 

The constrains list contains all of the operators that the immediately following axioms are 

intended to constrain. It is die responsibility of a specification checker to ensure that the specification 

conforms to this intent The constrained operators will generally be a proper subset of the operators 

appearing in the axioms. In this example the constrains list informs us that the axioms are not to 

put any constraints on the properties of if then else, false, 0, 1, +, |, and =, despite their occurrence 
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in the axioms. The judicious use of constrains lists is an important step in modularizing specifications. 
We associate a theory with every trait A theory is a set of well-formed formulas (wfFs) of typed 
first-order predicate calculus with equations as atomic formulas. 

The theory, call it Th, associated with a trait written in the Larch Shared Language is defined 
by: 

Axioms: Each equation, universally quantified by the variable declarations of the containing 

constrains clause, is in Th. 
Inequation: -(true = false) is in Th. All other inequations in Th are derivable from this one 

and the meaning of = . 
First-order predicate calculus with equality: Th contains the axioms of conventional typed 
first-order predicate calculus with equality and is closed under its rules of inference. 
The equations and inequations in Th are derivable from die presence of axioms in the trait — never 
from their absence. Th is deliberately small, because it is important to prove theorems before a 
specification is complete, and we wanted to limit the circumstances under which the addition of new 
operators and equations could invalidate previously proved theorems. Had we chosen to take the 
theory associated with either the initial or final interpretation of a set of equations (as in [ADJ 78] 
and [Wand 79]), this monotonicity property would have been tost 

2. Getting Richer Theories 

While the relatively small theory described above is often a useful one to associate with a set of 
axioms, there are times when a larger theory is needed, e.g., when specifying an "abstract data type." 
Generated by and partitioned by give different ways of specifying larger theories. 

Section 1 does not include an induction schema. This is an appropriate limitation when the set 
of generators for a sort is incomplete. Saying that sort S is generated by a set of operators, Ops, 
asserts that each term of sort S is equal to a term whose outermost operator is in Ops. One might, 
for example, say that the natural numbers are generated by and successor and the integers generated 
by 0, successor, and predecessor. Generated by adds an inductive rule of inference. 

This inductive rule and the clause Table generated by [ new, add ] can be used to derive theorems 
such as 

V* Table [ (/ = new) | (3irub Index [ ind € / ] ) ], 
that would otherwise not be in the theory. 
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Section 1 allows equations to be derived only by direct equational substitution, not by the 
absence of inequations. This is an appropriate limitation when the set of observers for a sort is 
incomplete. Saying that sort S is partitioned by a set of operators. Ops, asserts that if two terms of 
sort S are unequal, a difference can be observed using an operator in Ops. Therefore; they must be 
equal if they cannot be distinguished using any of the operators in Ops. This rule of inference adds 
new equations to the theory associated with a trait, thus reducing the number of equivalence classes 
in the equality relation. 

This rule and the clause Table partitioned by [ €, eval ] can be used to derive theorems such as 
add(addO, ind, v), indl, v) = add(addO, indl, v), ind, v), 
that would otherwise not be in the theory. 

3. Combining Independent Traits 

Our example contains a number of totally unconstrained operators, e.g., false and + . Such traits 
are not very useful The most straightforward thing to do would be to augment the specification with 
additional clauses dealing with these operators. One way to do this is by trait importation. We might 
add to trait TableSpec: 

imports Cardinal, Boolean 

The theory associated with the importing trait is the theory associated with the union of all of 
the introduces and constrains clauses of the trait body and the imported traits. 

Importation is used bom to structure specifications to make them easier to read and to introduce 
extra checking. Operators appearing in imported traits may not be constrained in either the importing 
trait or any other imported trait This guarantees that imported traits don't "interfere" with one 
another in unexpected ways. I.e., it guarantees that the theory associated with a trait is a conservative 
extension of each of the theories associated with its imported traits. (An extension, Thl, of a theory, 
Th2, is conservative if and only if every wff of the language of Th2 which is in Thl is also in Th2.) 
Each imported trait can, therefore, be fully understood independendy of the context into which it is 
imported. 

As a syntactic amenity, trait Boolean is automatically imported into all other traits. 
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4. Combining Interacting Traits 

While the modularity imposed by importation is often helpful it can sometimes be too restrictive. 

It is often convenient to combine several traits dealing with different aspects of the' same operator. 

This is common when specifying something that is not easily thought of as an abstract data type. 

Tfait inclusion involves the same union of clauses as trait importation, but allows the included 

operators to be further constrained. Consider, for example: 

Reflexive: trait 

introduces #.rel#: T, T -* Bool 
constrains .rel so that for all [ /: T ] 

t .rel / = true 

Symmetric: trait 

introduces #jrel#: T, T -* Bool 
constrains .rel so that for all [ //, t2: T ] 

// jel t2 = t2 .rel tl 

Transitive: trait 

introduces #.rel#: T, T -* Bool 
constrains .rel so that for all [ tl, t2, (3: T ] 

(((// .rel t2) & (t2 .rel t3)) =*• (// .rel t3)) = true 

Equivalence: trait 

includes Reflexive, Symmetric, Transitive 

Equivalence has the same associated theory as the less structured trait 

Equivalencel: trait 

introduces #.rel#: T, T -* Bool 
constrains .rel so that for all [ tl, t2, (3: T ] 

// .rel // = true 

// .rel 12 = t2 .rel // 

(((tl .rel t2) & (12 .rel t3)) -» (// .rel t3)) = true 
Any legal trait importation may be replaced by trait inclusion without either making the trait 
illegal or changing the associated theory. It does involve the sacrifice of the checking that ensures 
that the imported traits may be understood independently of the context in which they are used. We 
use importation when we can incorporate a theory unchanged, inclusion when we cannot 



5. Renaming and Exclusion 

The specification of Equivalence in the previous section relied heavily on the coincidental use 
of the operator .rel and the sort identifier T in three separate traits. In the absence of such happy 
coincidences, renaming can force names to coincide, keep them from coinciding, or simply replace 
them with more suitable names. 
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The phrase 

Tr with [ x for y ] 

stands for the trait Tr with every occurrence of y (which must be either a sort or op^ator identifier) 

replaced by x. Notice that if y is a sort identifier this renaming may change the signatures associated 

with some operators. 

~. Occasionally we wish to eliminate an operator altogether. The phrase 

Tr without [ op ] 

stands for the trait Tr without the declaration of op and without each axiom, generated by, and 

partitioned by in which op appears. We use without to remove an operator either so that we can later 

add another operator with the same name and signature but different properties or merely because 

it is superfluous and we want to spare readers the bother of looking at it 

If TableSpec contains the generated by and partitioned by of section 2, the specification 

ArraySpec: trait 

imports IntegerSpec 

includes TableSpec without [ size ] 

with [ defined for #€#, assign for add, read for eval 
Array for Table, Integer for Index ] 

stands for 

ArraySpec: trait 

imports IntegerSpec 
introduces 

new: -* Array 

assign: Array, Integer, Val -* Array 

defined: Integer, Array -» Bool 

read: Array, Integer -* Val 

isEmpty: Array -+ Bool 
constrains new, assign, defined, read, isEmpty so that 

Array generated by [ new, assign ] 

Array partitioned by [ defined, read ] 

for ail [ ind, indl: Integer, val: Val /: Array ] 

read(assign(/, ind, val), indl) — 

if ind = indl then val else read(4 indl) 

defined(/n4 new) = false 

definedO'nd/, assign(/, ind, val)) = ((ind = indl) | definedO/wtf, /)) 

Notice that in this specification isEmpty is totally unconstrained. In section 7 we discuss a 

checking mechanism that would call the lack of constraints on isEmpty to the specifier's attention. 

This would, presumably, provoke him either to add the axioms 

isEmpty(new) = true 
isEmpty(assign(/, ind, val)) = false 

to his specification, or to add isEmpty to the without clause. 

The use of without rather than some sort of hiding mechanism (as in [Burstall and Goguen 81D 

may thus involve some extra work for the specifier. In return for this work, users of the specification 

are spared having to deal with the "hidden" operators, e.g., in proofs that use the specification. This 
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is consistent with our belief that specifiers should be encouraged to do things that will make life 
easier for users of their specifications. 

The definition of without should make it clear that we are indeed operating on fie text of traits 
(presentations) rather than on their associated theories. Consider adding these isEmpty axioms to 
TableSpec to form another trait, TableSpecl. TableSpec and TableSpecl have the same associated 
theories, but 

TableSpec without size 
and 

TableSpecl without size 
have rather different associated theories— in the latter, isEmpty is fully defined. 

A final point raised by the examples of this section is the importance of distinguishing between 
the history of a specification (how it was constructed) and the structure presented to a reader. A 
reader familiar with TableSpec might prefer to read the first version of ArraySpec; others might find 
it distracting to have to understand the more general structure before understanding ArraySpec. 

6. Assumptions 

We often construct fairly general specifications that we anticipate will later be specialized in a 
variety of ways. Consider, for example, 
MultiSetSpec: trait 

introduces 

{}: -* Multiset 

insert: MultiSet, Elem -+ MultiSet 
delete: MultiSet, Hem -* MultiSet 
#€#: MultiSet, Elem -► Bool 
constrains {}, insert, delete, € so that 
MultiSet generated by [ {}, insert ] 
MultiSet partitioned by [ delete, € ] 
for all [ m: MultiSet, e, el: Elem ] 

e € {} = false 

e € insert(m, el) = (e = el) | (e € m) 

delete({}, e) = {} 

delete(insert(m, e), el) = 

if e = el then m else insert(delete(m, el), e) 

We might specialize this to IntMultiSet by renaming Elem to Integer and including it in a trait 

in which operators dealing with Integer are specified, e.g., 

IntMultiSet: trait 

imports IntegerSpec 

includes MultiSetSpec with [ Integer for Elem ] 
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The interactions between MultiSetSpec and IntegerSpec are very limited. Nothing in 

MultiSetSpec places any constraints on the meaning of the operators that occur in IntegerSpec, e.g., 

0, +, and <. Consider, however, extending MultiSetSpec to MultiSetSpecl by addmg an operator 

rangeCount 

MultiSetSpecl: trait 

imports MultiSetSpec, Cardinal 
introduces 

rangeCount: MultiSet Hem, Hem -»• Integer 

#<#: Hem. Hem -► Bool 
constrains rangeCount so that for all [ el, eX e3: Hem, nv MultiSet ] 

rangeCoun«({}, el, e2) = 

rangeCount(insert(m, ei), el, e2) - 

rangeCount(m, el, e2) + (if (el < eS) & (e3 < el) then 1 else 0) 

MultiSetSpecl places no constraints on the < operator. Suppose, however, that this is not what 

we intend. We might have definite ideas about the properties mat < must have in any specialization, 

e.g., that it should define a total ordering. We could specify such a restriction by adding to 

MultiSetSpecl the assumption (Ordered is defined in the Handbook section, on page 36): 

assumes Ordered with [ Hem for T ] 

In constructing the theory associated with MultiSetSpecl, the assumption would be treated as if 

Ordered with [ Hem for T ] had been included. This could be used to derive various properties of 

MultiSetSpecl, e.g., that rangeCount is monotonic in its last argument 

Whenever the augmented MultiSetSpecl is imported or included in another trait, however, the 

assumption will have to be be discharged. In 

IntMuMSetl: trait 

includes MultiSetSpecl with [ Integer for Hem ] 
imports IntegerSpec 

this would amount to showing that the (renamed) theory associated with Ordered is a subset of the 

theory associated with IntegerSpec. Often, the assumptions of a trait are used to discharge the 

assumptions of traits it imports or includes. 



7. Consequences 

We have now looked at those parts of the Larch Shared Language that determine the theory 
associated with a valid trait That subset of the language contains some checkable redundancy; e.g., 
assumptions are checked when a trait is included or imported, and constrains lists are checked against 
the axioms associated with them. We now turn to a part of the language whose only purpose is to 
introduce checkable redundancy, in the form of assertions about the theory associated with a trait 
There are two kinds of consequence assertions: 
That the theory associated with a trait contains another theory. 
That the theory associated with a trait "adequately" defines a set of operators in terms of 
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other operators. 
The first kind of assertion is made using implies. Consider, for example, adding to the augmented 
MultiSetSpecl, 

implies for all [nu MultiSet, el, e2, e3: Elem] 

(e2 < e3) ^ (rangeCount(m, el, e2) <£ rangeCount(m, el, e3)) 
Implies can be used to indicate intended consequences of a specification, both for checking and 
to increase the reader's insight The theory to be implied can be specified using the full power of 
the language, e.g., by using generated by and partitioned by, or by referring to traits defined elsewhere. 
The second kind of assertion is made using converts [ Ops L This asserts that each term is 
provably equal to a term that does not contain operators in Ops. (We do not require this for terms 
containing variables of sorts appearing in generated by clauses.) Converts is used to say that the 
specification adequately defines a collection of operators. 

A common problem with axiomatic systems is deciding whether there are "enough" axioms. 
Converts provides a way of making a checkable statement about the adequacy of a set of axioms. 
Consider, for example, adding to TableSpec: 

converts [ isEmpty ]. 
This says that each term containing isEmpty, such as isEmpty(new) or isEmpty(add(new), ind, ml)), 
is equal to another term that does not contain isEmpty. 

Now consider adding to TableSpec the stronger assertion: 
converts [ isEmpty, eval ]. 
Terms containing subterms of the form eval(new, ind) are not convertible to terms that do not contain 
eval, so an error message of the form 

eval(new, ind) not convertible 
would be generated This would present a problem if we did not wish to add an axiom to resolve 
this incompleteness. We therefore provide a mechanism to allow specifiers to indicate that the 
unconvertibility of certain terms is acceptable. If TableSpec were modifed to include 

exempts for all [ ind: Index ] eval(new, ind) 
the checking associated with the converts would now require that the theory associated with TableSpec 
must contain either 

an equation, t = tl, where tl has no occurrences of isEmpty or eval or 
an equation f = tl, where t' is a subterm of t, and tl is an instantiation of eval(new, ind). 
This checking ensures that each term containing operators in the converts list is either defined 
by the axioms (in terms of operators not in the list) or explicitly exempted. One use of converts is 
to allow the specification checker to notice unintended effects of without As suggested in section 6, 
the failure of ArraySpec to fulfill the converts inherited from TableSpec would trigger error messages 
of the form: 

isEmpty(new) not convertible 
isEmpty(assign(t ind vat)) not convertible. 
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8. IfThenElse and Equality 

In our examples we made use of some apparently unconstrained operators: if then else and =, 
with a variety of signatures. In fact, the appearance of these operators leads fe the implicit 
incorporation of the traits IfThenElse and Equality. 

Whenever a term of the form if b then tl else t2 occurs in a trait we replace the mixfix symbol 
if then else by the prefix symbol ifThenElse. If a and t2 are of the same sort, Tl, we also import 
the trait IfThenElse with f Tl for T ] into the enclosing trait 

Whenever a term of the form tl = t2 occurs in a trait, if tl and t2 are of the same sort, Tl, we 
append the trait Equality with [ Tl for T ] to the consequences of the enclosing trait 

Specifications of these traits are: 

IfThenElse: trait 

introduces ifThenElse: Bool, T, T -♦ T 
constrains ifThenElse so Oat for all [ //, 12: T ] 

ifThenElse(true, //, tl) = tl 

ifThenElse(false, //, tl) = t2 

implies converts [ ifThenElse ] 

Equality: trait 

includes Equivalence with [ = for .rel ] 
constrains = so that T partitioned by [ = ]. 



9. Some Further Examples 

The following series of examples is adapted from the Handbook chapter. We include them here 
to illustrate some ways in which the facilities introduced above can be used. In reading these 
specifications, keep in mind that they are not themselves ends, but rather means to write interface 
specifications. 

Our first example is an abstraction of those data structures that "contain" elements, e.g., Set 
Bag, Queue, Stack. We have found it useful both as a starting point for specifications of various 
kinds of containers, and as an assumption for generic operations. The crucial part of the trait is the 
generated by. It indicates that any term of sort C is equal to some term in which new and insert are 
the only operators with range C — even if this trait is included in one that introduces additional 
operators that return values of sort C. This means that any theorems proved by induction over new 
and insert will remain valid. 

Container: trait % Cs contain E's 

introduces 

new: -* C 
insert: C, E -* C 
constrains C so that C generated by [ new, insert ] 

The next example incorporates Container as an assumption. Notice that it constrains new and 

insert as well as the operator it introduces, isEmpty. The converts indicates that this trait contains 
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enough axioms to adequately specify isEmpty. Because of the generated by, this can be proved by 
induction over terms of sort C, using new as the basis and insertfc, e) in the induction step. 
IsEmpty: trait 

assumes Container 

introduces isEmpty: C -* Bool 

constrains isEmpty, new, insert so that for all [ c: C, e: E J 

isEmpty(new) = true 
isEmpty(insert(c, e)) - false 
implies converts [ isEmpty ] 
The next two examples assume Container. The exempts indicate that should these traits be 
included into a trait that claims the convertibility of next or rest, that trait needn't convert the terms 
next(new) or rest(new). 
Next: trait 

assumes Container 

introduces next: C -* E 

constrains next, insert so that for all [ e: E ] 

next(insert(new, e)) = e 
exempts next(new) 
Rest: trait 

assumes Container 

introduces rest: C -* C 

constrains rest, insert so that for all [ e: E ] 

rest(insert(new, e)) = new 
exempts rest(new) 
The next example specifies properties common to various data structures such as stacks, queues, 
priority queues, sequences, and vectors. It augments Container by combining it with IsEmpty, Next, 
and Rest. The partitioned by indicates that next, rest, and isEmpty are sufficient to define equality 
over terms of sort C. Since we have little information about next and rest, the partitioned by does 
not yet add much to the associated theory. 
Enumerable: trait 

imports IsEmpty, Next, Rest 

includes Container 

constrains C so that C partitioned by [ next rest, isEmpty J 
The next example specializes Enumerable by further constraining next, rest, and insert. Sufficient 
axioms are given to convert next and rest The axioms that convert isEmpty are inherited from the 
trait Enumerable, which inherited them from the trait IsEmpty. 
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PriorityQueue: trait 

assumes TotalOrder with [ E for T ] 

includes Enumerable 

constrams next, rest, insert so that for all [ q: C, e: E ] 

next(insert(4, e)) = 

if isEmptyiq) then e 

else if nextfc) ^ e then ncxt(q) else e 

rest(insert(4, e)) = 

if isEmptyiq) then new 

else if next(g) <, e then insert(rest(«), e) else q 

implies converts [ next, rest, isEmpty ] 

In a trait, such as PriorityQueue, that defines an "abstract data type" there will generally be a 

distinguished sort (C in this case) corresponding to the "type of interest" of [Guttag 75] or "data 

sort" of [Burstall and Goguen 81]. In such traits, it is usually possible to partition the operators whose 

range is the distinguished sort into "generators," those operators which the sort is generated by, and 

"extensions," which can be converted into generators. Operators whose domain includes the 

distinguished sort and whose range is some other sort are called "observers." Observers are usually 

convertible, and the sort is usually partitioned by one or more subsets of the observers and extensions. 

The next example illustrates a specialization of Container that does not satisfy Enumerable. It 

augments Container by combining it with IsEmpty and Cardinal, and introducing two new operators. 

Notice that we include Container, because we intend to constrain operators inherited from it, but 

import IsEmpty and Cardinal, because we do not intend to constrain any operator inherited from 

them. Constrains C is a shorthand for a constrains clause listing all the operators whose signature 

includes C. The partitioned by indicates that count alone is sufficient to distinguish unequal terms of 

sort C. Converts [ isEmpty, count, delete ] is a stronger assertion than the combination of an explicit 

converts [ count, delete ] with the inherited converts [ isEmpty ]. 

Multiset: trait 

assumes Equality with [ Hem for T ] 
imports IsEmpty, Cardinal 
includes Container with [ empty for new ] 
introduces count: Hem, C -* Bool 

delete: Hem, C -* C 
constrams C so that 

C partitioned by [ count ] 

for all [ c: C, el. e2: E ] 

count(empty, el) = 

count(insert(c, el), e2) = count(c, el) + (if el = e2 then 1 else 0) 

delete(empty, el) = empty 

delete(insert(c, el), e2) = 

if el = e2 then c else insert(delete(c, el), el) 
implies converts [ isEmpty, count, delete ] 
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The next example specifies a generic operator. It uses Enumerable as an assumption to delimit 

the applicability of this operator to containers for which it is possible to enumerate the contained 

elements. (To understand why we assume Enumerable rather than Container, imagine^tefining extOp 

fox a MultiSet) The exempts indictates that we do not intend to fully define the meaning of applying 

extOp to containers of unequal size. Notice mat elemOp is totally unconstrained in this trait This 

prevents us from having many interesting implications to state at mis stage. 

PairwiseExtension: trait 

assumes Enumerable 
introduces 

elemOp: E,E-»E 

extOp: C, C -* C 
constrains extOp so that for all [ cl, c2: C, el, e2: E ] 

extOp(new, new) = new 

extOp(insert(c/, el), insert(c2, e2)) = insert(extOp(c/, c2), elemOp(e/, e2)) 

implies converts [ extOp ] 
exempts for all [ c: C, e: E ] 

extOp(new, insert(c, e)), 

extOp(insert(c e), new) 

Now we specialize PairwiseExtension by binding elemOp to + over Cardinals: 

PairwisePlus: trait 

assumes Enumerable 

imports Cardinal 

includes PairwiseExtension with [ # + # for elemOp, # + # for extOp, Card for E ] 

implies Commutative with [ # + # for O, C for T J 

The validity of the implication that + for sort C is commutative stems from the replacement of 

elemOp by + for sort Card, whose constraints (in trait Cardinal) imply its commutativity. 
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Larch Shared Language Reference Manual 

0. Structure of Manual 

In section 1 we present a grammar for the kernel subset of the Larch Shared Language. 

In section 2 we define the context sensitive checking and the theory associated with each 
specification written in the kernel subset 

In section 3 we extend the kernel subset by introducing mechanisms for specifying intended 
consequences of a specification written in the kernel subset 

In sections 4-10 we define successive extensions of the language. We modify the grammar to 
introduce additional aspects of the language and describe any additional context sensitive checking 
required. We also provide a translation from the newly extended language to the previously defined 
subset The result of this translation is subjected to all the applicable checking. The theory associated 
with any specification written in the full language is the same as the theory associated with its 
translation. 

Section 11 describes additional checks, defined in terms of the theories associated with traits, 
that are associated with various language features. To be legal, a specification and each of the parts 
from which it is built must satisfy these checks as well as the context sensitive checks described 
earlier. 

Finally, section 12 collects the reference grammar for the entire language. 



20 



The Larch Shared Language 



1. Kernel Syntax 



/./. Syntactic conventions 

\~ 

{«} 

e* 

e* 

e + 

alpha 

alpha 

(') 

(e) 



alternative separator 

e is optional 

zero or more e's 

zero or more e's, separated by commas 

one or more e's 

alpha is a nonterminal symbol 

alpha is a terminal symbol 

parentheses as terminal symbols 

parentheses for grouping syntactic expressions 



1.2. Grammar 

trait 

traitBody 

simpleTrait 

opPart 

opDcl 

signature 

domain 

range 

propPart 

props 

generators 

partitions 

bylist 

sortedOp 

axioms 

varDcl 

equation 

term 

opld 

opForm 

opSym 

traitld 

sortld 

varld 

Comments 



: traitld : trait traitBody 

■■ simpleTrait 

■- {opPart} propPart* 

■■ introduces opDcl* 

■■ opld : signature 

■■ domain -» range 

■■ sortld*, 

■■ sortld 

■■ asserts props 

■■generators* partitions* axioms* 

■■ sortld generated bylist*, 

■■ sortld partitioned bylist*, 

■■ by I sortedOp*, ] 

■■ opDcl 

■■ for all I varDcl*, ] equation* 

■■ varld*, : sortld 

■ term — term 

■■ sortedOp { '( term*, ') } | varld 

■ alphaNumeric + \ opForm 

= { # } opSym ( # opSym )* { # } 

■■ specialChar + \ . alphaNumeric + 

■■ alphaNumeric + 

= alphaNumeric + 

■■ alphaNumeric + 

start with % and terminate with end of line. They may appear after any token. 
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2. Simple Traits 

2.1. Context sensitive checking 

simpleTrait: 
= The sets of varldX sortlcfs and opltfs appearing in a trait must be disjoint 
Every sortld appearing anywhere in a simpleTrait must appear in its opPart. 
Every sortedOp appearing anywhere in a simpleTrait must appear in its opPart. 

opDcl: 

Each opForm must have the same number of #'s as the number of occurrences of sortld 's in 
the domain. 

generators: 

The range of each sortedOp must be the sortld of the generators. 

At least one sortedOp in each by//sf must have a domain in which the sorf/d of the generators 
does not occur. 

part/ffons: 

The domain of each sortedOp must include the sorf/cf of the partitions. 

The range of at least one sortedOp in each bylist must be different from the sortld of the 
partitions. 

axioms: 

Each var/rf used in a farm must appear in exactly one varDcl. 
No varld may occur more than once in I varDcl*, ]. 

equation: 

The sorts of both term's must be the same, where 
The sort of a term of the form sortedOp { '( term*, ') } is the range of the sortedOp. 
The sort of a term of the form varld is the sorf/d of the varDcl in which the var/cf is declared. 

term: 

In sortedOp { '( farm*, ') } the domain of the sortedOp must be the sequence of the sorts of 
the farms in term*, . 
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2.2. Associated theory 

We associate a theory with each trait. This section defines the theory associated with a 
simpleTrait. 

A theory is a subset of the language: 

wff ::= term - term 

| "prepositional formula" 

| "first order quantified (with sorts) formula" 

We adopt the conventional meanings of the equality symbol (=), the prepositional connectives 
(&, I, ~, "*, ■■■). and the quantifiers (V and 3). 

The subset of wff that is the theory, call it Th, associated with a simpleTrait is defined by: 
Axioms: Each equation, universally quantified by the varDcfs of its containing axioms, is in 

Th. 
Inequation: ~(true:-*Bool = false:-+Bool) is in Th. 

First order predicate calculus with equality: Th contains the axioms of conventional typed 
first-order predicate calculus with equality and is closed under its rules of inference. 

Induction: If the trait has a generators with sortld S and a by//sf by [opi opj, and P(s) 

is a wff with a free variable, s, of sort S, Th contains the wff 

V[s: S] P(s) 

if for each opj in [opi, .... opj 

Qi => P(opi(xi Xk)) is in Th, where 

k is the arity of opi, 

the xj's are variables that do not appear free in P, and 
Qi is the conjunction of P(xj), for each j such that the j* argument of opj 
is of sort S. 

Reduction: If the trait has a partitions with sortid S and a bylist by [opi opj, Th contains 

the wff 

V[si, s 2 : S] (Q -» si = S2) 

where Q is the conjunction, for each opi in [opi opj and each j such that the j* 

argument of opj is of sort S, of 

V[xi: Si, x k : SJ (Subst(opi, j, ti) = Subst(opi, j, t2», where 

Si, . . ., St is the domain of opi, and 

Subst(op, j, t) is op(xi, . . . , xt) with t substituted for xj. 
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3. Consequences and Exemptions 

Exempts and consequences affect only the checking (see section 11.5) and do not affect the 
theory. We add to the grammar the productions: 

trait ::= traitld : trait traitBody {consequences} {exempts} 

consequences ::= implies conseqProps {converts} 

conseqProps :: = props 

converts '■'■= concerts conversion*, 

conversion ::= [ sortedOp*, ] 

exempts ::~ exempts exempt Terms* 

exemptTerms :: = { for all [ varDcl*, \ } term*, 

3.1. Context sensitive checking 

conseqProps: 

If the props of the conseqProps is appended to the propPart of the containing trait, the 

resulting trait must satisfy the checks of section 2. 

exempts: 

Each term must satisfy the checks of section 2.1. 

4. Constrains Clauses 

Constrains clauses affect only the checking (see section 11.4), not the theory. We add to the 
grammar the productions: 

propPart ::= ( asserts | constrains ) props 

constrains :: = constrains ( sortld | sortedOp*, ) so that 

4.1. Translation 

constrains: 

Replace the constrains by asserts. 



24 The Larch Shared Language 



5. Implicit Signatures and Partial OpForms 

In the kernel language each sortedOp is an opDcl. Here we relax this restriction to allow 
omitted and partial signatures and omitted #'s. We add to the grammar the production: 
sSrtedOp ::= opld { -* range } 

5:1. Context sensitive checking 

There must be a unique mapping from occurrences of sortedOp's to opDcCs of the traitBody 
such that the translation described in section 5.2. produces a legal traitBody and for each sortedOp, 
opDcl pair: 

The oplcfs match, i.e., 

They are the same, or 

They are both opForms and the one in the sortedOp is the same as the one in "the 
opDcl with all #'s removed. 
If the sortedOp includes -* range, it is the same as the range of the opDci. 

5.2. Translation 

The checking ensures that each occurrence of a sortedOp corresponds to a unique opDcl. The 
translation is simply to replace it by that opDcl. 

6. Mixfix Operators 

In the language presented thus far, all operators are treated as either miliary or prefix. Here we 
relax that restriction. We replace the grammar for term by: 
term 

secondary 
primary 



= secondary | if secondary then secondary else term 
= { opSym } primary ( opSym primary )* { opSym } 
= sortedOp { '( term*, ') } | varld \ '( term ') 



6.1. Translation 

equation: 

It is necessary to resolve the grammatical ambiguity between the = connective in equations 
and the = opSym. In any equation the first occurrence of = that is not bracketed by parentheses 
or within an if then else is the equation connective, the remainder are opSyms. Parentheses can be 
used to enforce any desired parsing. 
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term: 

Translate each term of the form tf b then ti else t2 into a tenn of the form ifTnenEbe(b, ti, t2>. 

secondary: 

Translate each secondary containing opSym's into a primary of the Jbnn opld '( term*, '% 

where 

opld is derived by replacing each primary in the secondary by #. 
term*, is die sequence of primary'*. 

primary: 

After the previous translations have been performed, remove die outer parentheses from 
primary's of the form *( term '). 



7. Boolean Terms as Equations 

It is convenient to use terms of sort Bool as axioms. We add to the grammar the production: 
equation ::= term 

7.1. Context sensitive checking 
The term must be of sort Bool. 

7.2. Translation 

Replace the term by the equation 
term - true 
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8. External References 



We add to the kernel grammar the productions: 



traitBody 

externals 

assumes 

imports 

includes 

traitRef 

conseqProps 



= externals simpleTrait 

= {assumes} {imports} {includes} 

= assumes traitRef*, 

- imports traitRef*, 

- includes traitRef*, 
= traitld 

= traitRef*, props 



8.1. Context sensitive checking 

externals: 

Recursive externals are not permitted; i.e., the traitld of the containing trait may not appear in 
an externals, nor in any partial translation of a traitRef in its externals. 

8.2. Translation 

The translation of a trait is derived bottom-up; i.e., before a trait with traitRefs is translated, 
each of its traitRefs is replaced by the translation of the trait labeled by that traitRefs traitld. Let 
T be a trait whose simpleTrait is S and let E consist of the translations of the traitRefs in Ts 
externals. The translation of T consists of: 

An opPart containing S's opDcIs and E's opDcis, 
A propPart* containing S's propPart's and E's propPart's, 
An exempts containing Ts exemptTerms and E's exemptTerms, and 
A consequences containing the props of 
Ts conseqProps, 

the propParts of the translations of the traitRefs in Ts conseqProps, and 
E's consequences. 
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9. Modifications 

We add to the grammar the productions: 



traitRef 

exclusion 

renaming 

sortRename 

oldSort 

opRename :: = opld for oldOp 

oldOp ::= sortedOp 



= traitld {exclusion} {renaming} 

= without [ oldOp*, ] 

= with [ ( sortRename | opRename )*, ] 

= sortld for oldSort 

= sortld 



9.1. Context sensitive checking 

traitRef: 

No sortedOp may occur more than once as an oldOp. 
No sortld may occur more than once as an oldSort. 

Each oldSort must appear in an opDcl in the translation of the trait labeled by the traitld. 
There must be a unique mapping from oldOp's to opDcrs of the translation of the trait labeled 
by the traitld, such that for each oldOp, opDcl pair: 
The opIcTs match (see section 5.1), 

If the oldOp includes domain, it is the same as the domain of the opDcl. 
If the oldOp includes -* range, it is the same as the range of the opDcl. 

9.2. Translation 

The translation of the trait labeled by the traitld of the traitRef is modified by applying first 
the exclusion, then the opRename's, and finally the sortRename's: 

For each oldOp in the exclusion, delete each bylist, equation, and term containing the 

opDcl to which it maps and then delete all remaining occurrences of that opDcl. 
Then, simultaneously, for each opRename, replace the opld part of each occurrence of the 

opDcl to which the oldOp maps by the opld of the opRename. 
Finally, simultaneously, for each sortRename, replace each occurrence of its oldSort by its 
sortld. 
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10. Implicit Incorporation of Boolean, IfThenElse, and Equality 

Three traits, Boolean, IfThenElse, and Equality, are implicitly incorporated into various other 
traits to assure uniform meanings for the operators they constrain. 

10.1. Translation 

Append the traitRef Boolean to the imports of each trait except Boolean. 

Append the traitRof IfThenElse with [ Tl for T ] to the imports of each trait containing a term 
of the form if b then ti else ti in which ti and t2 have the same sort, Tl. 

Append the traitRef Equality with [ Tl for T ] to the traitRaf* of the conseqProps of each 
trait (except Equality) containing a term of the form ti = ti in which ti and t2 have the same sort, 
Tl. 

10.Z Built-in traits 

Boolean: trait 

introduces 

true: -+ Bool 
false: -* Bool 
~#: Bool -► Bool 
#&#: Bool, Bool -•> Bool 
#|#: Bool, Bool -* Bool 
#=»#: Bool, Bool -* Bool 
#. equal*: Bool, Bool — Bool 
asserts Bool generated by [ true, false ] 
for all [ b: Bool ] 

-true = false 

-false = true 

(true & b) = b 

(false & b) = false 

(true | b) = true 

(false | b) = b 

(true ■» b) = b 

(false ■» b) = true 

(true .equal b) = b 

(false .equal b) = ~b 

implies converts [ ~, &, |, =*, .equal ] 

IfThenElse: trait 

introduces ifThenElse: Bool, T, T -*■ T 
asserts for all [ //, t2: T ] 

ifThenElse(true, //, i2) = tl 

ifThenElse(false, //, t2) = t2 

implies converts [ ifThenElse ] 
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Equality: trait 

introduces # = #: T, T — Bool 
asserts T partitioned by [ = ] 
for all [ x, y. z: T ] 

(x=y) = (v=jr) 
((x=y)Sc(y=z))=*>(x=z) 



11. Semantic Checking 



In addition to the syntactic constraints specified above, we require that each trait be logically 
consistent, discharge the assumptions of the traits it is built from, be a conservative extension of its 
imports, be properly constraining, and imply its consequences. 

11.1. Consistency 

A traitBody is consistent if its associated theory does not contain the equation 
true:-*Bool = false:-»Bool 

11.2. Assumptions 

Let A(T) be all of the assumes of the traits imported or included in T, and R(T) be the result 
of translating T after removing these assumes. A(T) is discharged by T if the theory associated with 
the translation of each traitRef of A(T) is a subset of the theory associated with R(T). 

11.3. Imports 

The theory associated with a trait must be a conservative extension of the theory associated with 
the translation of each traitRef in its imports; i.e., if trait Tl imports T2 and W is a wff of T2, W 
is in the theory associated with Tl if and only if it is in the theory associated with T2. 

11.4. Constraints 

A propPart is properly-constraining if it implies properties of only the operators in its constrains. 
The occurrence of a sortld in a constrains stands for the list of all sortedOp's in the containing 
trait's opPart whose signatures include that sortld. 

Let T be a trait and P be the propPart constrains sortedOp*, so that props. P is 
properly-constraining in the trait consisting of T plus P if and only if each wff in the theory associated 
with T plus P is also in the theory associated with T or else contains ops in sortedOp*. 

Note that, since the translation of a traitRef converts constrains to asserts, this check is performed 
only on traits in which constrains appears explicitly. 
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11.5. Consequences 

A trait implies its consequences if the theory associated with its conseqProps is a subset of 
the theory associated with the trait and the [ sortedOp*, ] in each converts is convertible. 
Convertibility is defined using the theory and exempts of a trait. 

conseqProps: 

The theory associated with conseqProps must be a subset of the theory of the trait in which 
the consequences appears. The theory associated with a conseqProps is the theory associated with 
the trait body: 

includes traitRef*, opPart asserts props 
where traitRef*, and props form the conseqProps, and opPart is the opPart of the trait in which 
the consequences appears. 

Note that an exclusion, but not a renaming, can invalidate a consequence that has been locally 
checked. 

conversion: 

Let C be a conversion. For each term, t, that contains no variables of any sort appearing in a 
generators in the containing trait, the theory of the containing trait must either 
contain an equation t = u, 

where u contains no sortedOp appearing in Cs sortedOp*, or 
contain an equation t' = u, 

where t' is a subterm of t, and u is an instantiation of a term appearing in an exempts 
of the containing trait 
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11 Reference Grammar for The Larch Shared Language 



trait 

traitBody 

externals 

assumes 

imports 

includes 

traitRef 

exclusion 

renaming 

sortRename 

oldSort 

opRename 

oldOp 

sortedOp 

simpleTrait 

opPart 

opDcl 
signature 
domain 
range 

propPart 

constrains 

props 

generators 

partitions 

bylist 

axioms 

varDcl 

equation 

term 

secondary 

primary 

opld 

opForm 

opSym 

traitld 

sortld 

varld 

consequences 

conseqProps 

converts 

conversion 

exempts 

exemptTerms 



::= traitld : trait traitBody {consequences} {exempts} 

::= externals simpleTrait 

::= {assumes} {imports} {includes} 

::= assumes traitRef*, 

::= imports traitRef*, 

::= includes traitRef*, 

::= traitld {exclusion} {renaming} 

::= without [ oldOp*,] 

::= with [ ( sortRename \ opRename )*, \ 

:: = sortld for oldSort 

::= sortld 

::= opld for oldOp 

::= sortedOp 

::= opDcl \ opld { -* range } 

::= {opPart} propPart* 

::= introduces opDcl* 

:: = opld : signature 
::= domain -* range 
::= sortld*, 
::= sort/tf 

::= ( asserts | constrains ) props 

:: = constrains ( sortld \ sortedOp*, ) so that 

::= generators* partitions* axioms* 

::= sortld generated bylist*, 

:: = sortld partitioned bylist*, 

::= by [sortedOp*, J 

:: = for all [ varDcl*, ] equation* 

::= varld*, : sortld 

::= form { ■ term } 

::= secondary \ if secondary then secondary else form 

::= { opSym } primary ( opSym primary )* { opSym } 

::= sortedOp { '( form*, ') } | varld \ '( term ') 

::= alphaNumeric + | opForm 

::={#} opSym ( # opSym )* { # } 

::= specialChar + \ . alphaNumeric* 

::= alphaNumeric + 

::= alphaNumeric + 

::= alphaNumeric + 

::= implies conseqProps {converts} 

::= traitRef*, props 

::= converts con version*, 

::= [ sortedOp*,] 

::= exempts exemptTerms* 

:: = { for all [ varDcl*, ] } term*. 
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Towards A Larch Shared Language Handbook 

Contents 

Basic properties of single operators, including binary relations 

Associative, Commutative, Idempotent, Relation, TotalRelation, Reflexive, Irreflexive, 
Transitive, ReflexiveTransitive, Symmetric, Antisymmetric, Equivalence 

Ordering relations 

PartialOrder, TotalOrder, OrderEquivalence, OrderEquality, PartialOrderWithEquality, 
TotalOrderWithEquality, DerivedOrders, PartiallyOrdered, Ordered 

Group theory 

Leftldentity, Rightldentity, Identity, Leftlnverse, Rightlnverse, Inverse, Abelian, Semigroup, 
Monoid, Group, AbelianSemigroup, AbelianMonoid, AbelianGroup, Distributive 

Simple numeric types 

Ordinal, Cardinal, Cardinal 
Simple data structures 

Pair, Triple, FiniteMapping 

Container properties 

Container, Singleton, IsEmpty, Size, AdditiveSize, Join, ElementEquality, Member, 
ElemCount, Delete, Containment, Next, Rest, Remainder, Index 

Container classes 

SetBasics, BagBasics, CollectionExtensions, Setlntersection, Set, Bag, Enumerable, 
InsertionOrdered, Stack, Queue, Dequeue, Sequence, Subsequence, String, PriorityQueue 

Generic operators on containers 

CoerceContainer, Reduce, SomePass, AllPass, Sift, PairwiseExtension, Pointwiselmage 
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Nonlinear structures 

Binary Tree, BasicGraph, Connectivity, Graph 
Rings, fields, and numbers 

Ring, RingWithUnit, Infixlnverse, Integer, Field, Rational 
Lattices 

ExtremalBound, Semilattice, Lattice 
Enumerated data types 

Enumerated, Rainbow, Character 
Display traits 

Coordinate, Illumination, Boundary, Transform, Displayable, Picture, Contents, Component, 
ComponentCoercion, View, Display 
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Preface 



This collection of traits is a companion to the Larch Shared Language Reference Manual. We 
hope that it will serve three distinct purposes: 

Provide a set of components that can be directly incorporated into other specifications, 
Provide a set of models upon which other specifications can be based, and 
Heh) people to better understand the Larch Shared Language by providing a set of illustrative 
examples. 

In line with our first goal, we have tried to isolate the "smallest useful increments" of specification 
that it might be reasonable to use in other specifications. In particular, we have tried to provide traits 
that will make it convenient to specify the weak assumptions that characterize many of the more 
widely applicable specifications. This is particularly evident in the sections titled "Container 
properties" and Container classes." The traits in these sections are smaller and more numerous than 
is typical in "from scratch" specifications. This sometimes leads to a somewhat overstructured 
appearance. 

In line with our second goal, in addition to traits that we expect to be directly incorporated in 
specifications, we have included a number of traits intended primarily as patterns. The section titled 
"Generic operators on containers" contains several such traits. Because of the arity of the operators, 
it will frequently be awkward to incorporate these traits. 

In line with our third goal we have stressed familiar examples. Since they describe well-understood 
mathematical entities, many of the traits, e.g., Integer, are atypically complete. In general, we expect 
most specifications to supply constraints, rather than complete definitions. The section on Display 
traits is more typical in this respect 

The support tools envisioned for Larch are not yet available. Transcriptions of traits in this 
chapter have been mechanically checked for some properties; some errors may not have been detected 
and some transcription errors may have crept in. They should be given the same sort of credence as 
carefully written programs that have not been checked by a compiler. 

Comments on the clarity of these specifications and on their "correctness" (relative to generally 
accepted definitions of the names used) are welcome. We also solicit contributions of further widely 
useful traits — either accompanied by specifications, or as challenges to specifiers. 

Conventions 

If a generic trait constrains only one interesting sort, the identifier T is used to denote it 
If a trait constrains a "containing" sort and an "element" sort, the identifiers C and E are used. 
If a trait constrains a single binary operation, the infix symbol #0# is used. 
If a trait constrains a single binary relation, the infix identifier #®# is used. 
If there would be no information in a constrains (e.g., because there is only one operator), 
asserts is used. 
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Basic Properties of Single Operators, Including Binary Relations 

Associative: trait 

introduces #0#: T,T-»T 

asserts for all [ x,y, z: T ] (x O y) O z = x O (y O z) 

Commutative: trait 

introduces #0#: T, T -»• Range 

asserts for all [ x, y: T ] xO y = yO x 

Idempotent: trait 

introduces op: T -* T 

asserts for all [ x: T ] op(op(x)) = op(x) 

Relation: trait 

introduces #®#: T, T -* Bool 
TotalRelation: trait 

includes Relation 

asserts for all { x, y: T ] (x <B> v) | (y ® x) 

Reflexive: trait 

includes Relation 

asserts for all [ jc: T ] jc ® jc 

Irreflexive: trait 

includes Relation 

asserts for all [ x: T ] ~(jc ® jc) 

Transitive: trait 

includes Relation 

asserts for all [ x, y, z: T ] ((jc <B> v) & (y ® z)) ■* (jc ® z) 

ReflexiveTransitive: trait 

includes Reflexive, Transitive 

Symmetric: trait 

includes Relation 

asserts for all [ x, y: T ] (jc <8> v) = (y ® x) 

implies Commutative with [ <B> for O, Bool for Range ] 

Antisymmetric: trait 

includes Relation 

asserts for all [ x, y: T ] ~((jc ® v) & (y ® jc)) 

implies Irreflexive 

Equivalence: trait 

includes ReflexiveTransitive with [ .eq for ® ], 
Symmetric with [ .eq for ® ] 
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Ordering Relations 

PartialOrden trait 

imports ReflexiveTransitive with [ < for <B> ] 
TotalOrder: trait 

includes PartialOrder, TotalRelation with [ <, for ® ] 

OrderEquivalence: trait 

assumes PartialOrder 

introduces #.eq#: T, T -• Bool 

constrains .eq so that for all [ x, y: T ] (x .eq v) = (x < v) & (y < x) 

implies Equivalence 

converts [ .eq ] 

OrderEquality: trait 

assumes PartialOrder 

includes OrderEquivalence with [ = for .eq ], Equality 

PartialOrderWithEquality: trait 

includes PartialOrder, OrderEquality 
TotalOrderWithEquality: trait 

includes TotalOrder, OrderEquality 

DerivedOrders: trait 

assumes PartialOrder 
introduces 

#<#: T, T -► Bool 

#£#: T, T-» Bool 

#>#: T, T-*- Bool 
constrains < so that for all [ x, y: T J (x < y) = ((x < y) & (~(y < x))) 
constrains > so Aat for all [ x, y: T j (or > y) = (y < jc) 
constrains > so that for all [ x, y: T ] (x > y) = (y < x) 
implies Transitive with [ < for ® ], 

Transitive with [ > for <B> ], 

Antisymmetric with [ < for ® ], 

Antisymmetric with [ > for ® ], 

PartialOrder with [ > for ^ ] 
converts [ <, ^, > ] 

PartiallyOrdered: trait 

imports PartialOrderWithEquality 

includes DerivedOrders 

implies PartialOrderWithEquality with [ > for < ] 

Ordered: trait 

imports TotalOrderWithEquality 

includes DerivedOrders 

implies PartiallyOrdered, TotalOrderWithEquality with [ > for < ] 
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Group Theory 



Leftldentity: trait 

introduces 

#0#:T, T-»>T 
unit: -► T 
asserts for all [ x: T J unit O x = x 

Rightldentity: trait 

introduces 

#0#:T, T-+T 
unit: -*• T 
asserts for all [ x: T ] x O unit = x 

Identity: trait includes Leftldentity, Rightldentity 

Leftlnverse: trait 

assumes Leftldentity 

introduces inv: T -* T 

asserts for all [ x: T ] inv(jc) O x = unit 

Rightlnverse: trait 

assumes Rightldentity 

introduces inv: T -♦ T 

asserts for all [ x: T ] x O inv(jc) = unit 

Inverse: trait 

assumes Identity 

includes Leftlnverse, Rightlnverse 

Abelian: trait imports Commutative with [ T for Range ] 

Semigroup: trait includes Associative, Equality 

Monoid: trait includes Semigroup, Leftldentity 

Group: trait 

includes Monoid, Leftlnverse 
implies Rightldentity, Rightlnverse 

AbelianSemigroup: trait includes Abelian, Semigroup 

AbelianMonoid: trait 

includes Abelian, Monoid 
implies Rightldentity 

AbelianGroup: trait includes Abelian, Group 

Distributive: trait 

introduces 

# + #:T,T-»T 
#*#: T, T -•> T 
asserts for all [ x, y, 2: T ] 

x*(y + z) = (x*y) + (x*z) 
(y + z)*x = (y*x) + (z*x) 
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Simple Numeric Types 

Ordinal: trait 

includes PartialOrder with [ = for .eq, Ord for T ], 

OrderEquivalence with [ = for .eq, Ord for T ] 
introduces 

first: -* Ord 
succ: Ord -*■ Ord 
asserts Ord generated by [ first, succ ] 
Ord partitioned by [ ^ ] 
for all [ x, y: Ord ] 
firsts x 
~(succ(x) < first) 
succOr) <£ succ(y) = x < y 
implies TotalOrderWithEquality with [ Ord for T ] 
converts [ <., = ] 

Cardinal: trait 

imports Ordinal with [ for first, Card for Ord ] 
includes DerivedOrders with [ Card for T ] 
introduces 

1: —Card 

# + #: Card, Card -♦ Card 

#*#: Card, Card -*■ Card 

#©#: Card, Card -* Card 
constrains 1 so that 1 = succ(0) 
constrains +, * so that for all [ x, y: Card ] 

x + = x 

x + succ(y) = succ(x + y) 

jc*0 = 

jf*succO-) = x + (x*y) 
constrains G so that for all [ x, y: Card ] 

00 x = 

xQQ = x 

succ(x) siicc(y) = x © y 
implies Cardinal2 

Card generated by [ 1, +, ] 

Card partitioned by [ > ], by [ = ], by [ < ], by [ > ] 

for all [ x, y: Card ] x < y = ((x © y) = 0) 
converts [ 1, 0, +, *, =, <, >,<•>] 
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Cardinal2: trait % Alternate definition for comparison 

includes AbelianMonoid with [ + for O, for unit, Card for T ], 

AbelianMonoid with [ * for O, 1 for unit, Card for T ], 

Distributive with [ Card for T ], 

Ordered with [ Card for T ] 
introduces 

#0#: Card, Card -»• Card 

succ: Card -* Card 
asserts Card generated by [ 0, 1, + ] 

for all [ x, y: Card ] 
x < (jc + 1) 
(x + y) G y = x 

o e x = o 

succ(jc) = x + 1 
implies Cardinal 
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Simple Data Structures 

Pain trait 

introduces 

<#, #>: Tl, T2 -*■ C 

# .first: C -► Tl 

# .second: C -► T2 
asserts C generated ay [ <#, #> ] 

C partitioned by [ .first, .second ] 
for all [/Tl, rT2J 

<f, s>.first = f 

<f, sXsecond = s 
implies converts [ .first, .second ] 

Triple: trait 

introduces 

<#, #, #>: Tl, T2, T3 -* C 
#. first: C -* Tl 
#. second: C -* T2 
#. third: C -* T3 
asserts C generated by [ <#, #, #> ] 

C partitioned by [ .first, .second, .third ] 
for all [/-Tl, s:T2, t : T3 ] 

<f, s, tXfirst = f 

<f, s, tXsecond = s 

<f, s, t>.fliird = t 
implies converts [ .first, .second, .third ] 

FiniteMapping: trait 

assumes Equality with [ Index for T ] 
introduces 

new: -* C 

bind: C, Index, E -*■ C 

#[#]: C, Index -► E 

defined: C, Index -♦ Bool 
asserts C generated by [ new, bind ] 

C partitioned by [ #[#], defined ] 
constrains C so that 

for all [ c: C, t, il: Index, e: E ] 

bind(c, il, e)[i] = if i = il then e else c[i] 
~defined(new, i) 

defined(bind(c, //, e), i) = (/ = il) | defined(c, /) 
implies converts [ #[#], defined j 
exempts for all [ /: Index ] new[/] 
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Container Properties 

Container trait 

introduces 

new: -»■ C 
insert: C, E -► C 
asserts C generated by [ new, insert ] 

Singleton: trait 

assumes Container 

introduces singleton: E -* C 

constrains singleton so that for all [ e: E ] 

singleton(e) = insert(new, e) 
implies converts [ singleton J 

IsEmpty: trait 

assumes Container 
introduces isEmpty: C -* Bool 
asserts for all [ c: C, e: E ] 

isEmpty(new) 

~isEmpty(insert(c, e)) 
implies converts [ isEmpty ] 

Size: trait 

assumes Container 
imports Cardinal 
introduces size: C -* Card 
constrains size so that 
size(new) = 

AdditiveSize: trait 

assumes Container 

includes Size 

constrains size, insert so that for all [ c: C, e: E ] 

size(insert(c, e)) - size(c) + 1 
implies converts [ size ] 

Join: trait 

assumes Container 

introduces #.join#: C, C -* C 

constrains .join so that for all [ c, cl: C, &• E ] 

c .join new = c 

c .join insert(cA e) — insert(c join cl, e) 
implies converts [ .join ] 

QementEquality: trait imports Equality with [ E for T J 

Member: trait 

assumes Container, QementEquality 

introduces #€#: E, C -*■ Bool 

constrains €, insert so that for all [ c: C, e, el: E ] 

~(e € new) 

e € insert(c, el) = (e — el) \ (e € c) 
implies converts [ € ] 
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ElemCount: trait 

assumes Container, HementEquality 

imports Cardinal 

introduces count: C, E -* Card 

constrams count, insert so that for all [ e, el: E, c: C ] 

count(new, e) = 

count(insert(c, e), el) = count(c, e) + (if e = el then 1 else 0) 
implies converts [ count ] 

Delete: trait 

assumes Container 

introduces delete: C, E -» C 

constrains delete so that for all [e:E] delete(new, e) = new 

Containment: trait 

assumes Container 

includes PartiaUyOrdered with I C for <, D for >, Q for ^, 2 for £, C for T ] 



constrains C so Oat for all [ e: E, c: C ] 
implies for all [c:C] 

Next: trait 

assumes Container 

introduces next: C -* E 

constrams next, insert so that for all [ e: E ] 

exempts next(new) 

Rest: trait 

assumes Container 

introduces rest: C -* C 

constrams rest, insert so that for all [ e: E ] 

exempts rest(new) 

Remainder: trait 

assumes Container, Rest 

imports Cardinal 

introduces remainder: C, Card -*■ C 

constrains remainder so that for all [ c: C, i: Card ] 

remainder^, 0) = c 

remainder(c, i + 1) = remainderCrestCc), i) 
implies converts [ remainder ] 

Index: trait 

assumes Container, Next, Rest 

imports Cardinal 

introduces #{#]: C, Card -* E 

constrams #[#] so that for all [ c: C, /': Card ] 

cfl] = next(c) 

40 + 1)] = rest(cX«l 
implies converts [ #[#] ] 
exempts for all [ c: C ] c(0] 



c Q insert(c, e) 
new Q c 



next(insert(new, e)) = e 



rest(insert(new, e)) - new 
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Container Classes 

SetBasics: trait 

assumes ElementEquality, Container with [ {} for new ] 
includes Size with [ {} for new ], 

Member with [ Q for new ] 
introduces delete: C,E-»C 
constrains C so that 

C partitioned by [€ ] 

for all [ r C, e. el: E ] 

size(insert(s, e)) = size(s) + (if e € s then else 1) 
el € deleted; e) = (el € s) & (~(e = el)) 
implies Delete with [ {} for new ] 
converts [ size, delete, € ] 

BagBasics: trait 

assumes ElementEquality, Container with [ {} for new ] 
imports AdditiveSize with [ {} for new ], 

QemCount with [ {} for new ] 
includes Member with [ {} for new ] 
introduces delete: C, E -*■ C 
constrains C so that 

C partitioned by [ count ] 

for all [ b: C, e, el: E ] 

count(delete(6, e), el) = count(6, el) - (if e = el then 1 else 0) 
implies Delete with [ {} for new ] 
converts [ size, delete, count, € ] 

CollectionExtensions: trait 

assumes ElementEquality, Container with [ {} for new ] 
imports IsEmpty with [ {} for new ], 

Singleton with [ {} for new, {#} for singleton ], 

Containment with [ {} for new ], 

Join with [ {} for new, U for .join ] 
includes Equality with [ C for T ] 
implies converts [ {#}, isEmpty, U ] 

Setlntersecuon: trait 

assumes SetBasics 

introduces fl: C, C -► C 

constrains C so that for all [ & si: C, e, el: E ] 

e € (s n si) = (e € s) & (e € si) 
converts [ n ] 

Set: trait 

assumes ElementEquality 

imports SetBasics, Setlntersecuon 

includes CollectionExtensions 

implies Abelian with [ U for O, C for T ], 

Abelian with [ D for O, C for T ] 
converts [ size, delete, €, D, U, {#}, isEmpty, =, C, D, C, D ] 
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Bag: trait 

assumes ElementEquality 

imports BagBasics 

includes CollectkmExtensions 

implies Abelian with I U for O, C for T J 

converts [ size, delete, count, €, U, {#}, isEmpty, =, C, D, £, 2 ] 

Enumerable: trait 

imports IsEmpty, Next, Rest 

includes Container 

constrains C so that C partitioned by [ next, rest, isEmpty ] 

InsertionOrdered: trait % For assuming "Stack or Queue" 

includes Enumerable 

introduces isFIFO: -* Bool 

constrains next, rest, insert so mat for all [ c: C, e: E] 

next(insert(c, e)) = if isEmpty(c) | isFIFO then e else next(c) 
rest(insert(c, e)) = if isEmpty(c) | isFIFO men c else insert(rest(c), e) 

implies converts [ next, rest ] 

Stack: trait 

includes InsertionOrdered win [ push for insert, top for next, pop for rest, 

true for isFIFO ] 
implies for all [ stk: C, e: E ] 

top(push(rtft, e)) = e 

pop(push(s//c, e)) = stk 

Queue: trait 

includes InsertionOrdered with [ first for next, false for isFIFO ] 

implies for all [ q: C, e: E ] 

first(insertte, e)) = if isEmpty(«) men e else first($) 
rest(insert(?, e)) = if isEmpty(9) then new else insert(rest(«), e) 

Dequeue: trait 

includes Stack with [ insert for push, first for top, rest for pop ], 
Stack with [ enter for push, last for top, prefix for pop ] 

constrains C so that for all [ c: C, e, el: E ] 
insert(new, e) = enter(new, e) 
insert(enter(c, e), el) = enter(insert(c, el), e) 

implies Queue, Queue with [ enter for insert, last for first, prefix for rest ] 

converts [ insert, first, last, rest, prefix], [ enter, first, last, rest, prefix ] 

Sequence: trait 

imports Dequeue, AdditiveSize 
includes Index with [ first for next ], 

Join with [ || for .join ] 
implies C partitioned by [ size, #[#] ] 

SubSequence: trait 

imports Sequence 

includes Remainder with [ #[#...] for remainder ], 

Remainder with [ #[...#] for remainder, prefix for rest ] 
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String: trait 

imports Character 

includes Sequence with { length for size, Char for E ] 

PriorityQueue: trait 

assumes TotalOrder with [ E for T ] 
includes Enumerable 

constrahis next, rest, insert so that for all { g: C, e: E ] 
next(insert(9, e)) = if isEmptyC?) then e 

dse if nextCg) «£ e then nextfa) else e 
rest(insert(fl, e)) = tf isEmptyd) then new 

else if next(g) ^ * then insert(rest(4), e) else 4 
implies converts [ next, rest, isEmpty ] 



Generic Operators on Containers 

CoerceContainer: trait 

assumes Container with [ DC for C J, 

Container with [ RC for C ] 
introduces coerce: DC -» RC 
constrains coerce so that for all [ dc: DC, e: E ] 

coerce(new) = new 

coerce(insert(dt, e)) = insert(coerce(</c), e) 
implies converts [ coerce j 

Reduce: trait 

assumes Enumerable, 

Rightldentity with [ E for T ], 

Associative with [ E for T ] 
introduces reduce: C -* E 
constrahis reduce so that for all [ c: C ] 

reduce(c) = if isEmpty(c) then unit else next(c) O reduce(rest(c)) 
implies converts [ reduce ] 

SomePass: trait 

assumes Container 
introduces 

test: E T -+ Bool 

somePass: C, T -► Bool 
constrains somePass so that for aU [ c: C, e: E, t: T ] 

~somePass(new, /) 

somePass(insert(c, e), t) = tesu>, t) | somePass(c, /) 
implies converts [ somePass ] 
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AllPass: trait 

assumes Container 
introduces 

test: E, T -♦ Bool 

allPass: C, T -*■ Bool 
constrains allPass so Oat for ail [ c: C, e: E, t: T ] 

allPass(new, t) 

allPass(insert(c, e), t) = test(e, & allPass(c, 
implies converts [ allPass ] 

Sift: trait 

assumes Container 
introduces 

test: E, T -* Bool 

sift: C, T -* C 
constrains sift so that for all [ c: C, e: E, /: T ] 

sift(new, t) = new 

sift(insert(c, e), t) = if testt>, /) then insert(sift(c, t), e) else sift(c, /) 
implies converts [ sift ] 

PairwiseExtension: trait 

assumes InsertionOrdered 
introduces 

extOp: C, C -► C 

elemOp: E,E-»E 
constrains extOp so that for all [ cl, c2: C, el, el: E ] 

extOp(new, new) = new 

extOp(insert(c/, el), insert(c2, e2)) = insert(extOp(c/, c2), elemOp((?/, e2)) 
implies converts [ extOp ] 
exempts for all [ c: C, &• E ] 

extOp(new, insert(c, e)\ 

extOp(insert(c, e), new) 

Pointwiselmage: trait 

assumes Container with [ DC for C, DE for E ], 

Container with [ RC for C, RE for E ] 
introduces 

extOp: DC -» RC 

pointOp: DE -+ RE 
constrains extOp so that for all [ dc: DC, de: DE ] 

extOp(new) = new 

extOp(insert(dt, de)) = insert(extOpO/e), pointOp(rfe)) 
implies converts [ extOp ] 
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Nonlinear Structures 

BinaryTree: trait 

imports Cardinal 
introduces 

<#>: E-*C 
<#, #>: C, C -♦ C 
#.left: C -► C 
#.right: C -* C 
size: C -* Card 
isLeaf: C-* Bool 
content: C -» E 
constrains C so that 

C generated by [ <#>, <#, #> ] 
C partitioned by [ .left, .right, content, isLeaf ] 
for all [ tl, tr: C, e: E ] 
(<//, /r>).left = // 
(<//, *r>).right = tr 
size(<«>) = 1 

size(<//, tr>) = size(//) + size(fr) 
isLeaftXe>) 
-isLeaftX//, tf>) 
content(<e>) = e 
implies for all [ /.* C ] isLeaf) = (size(0 = 1) 
converts [ .left, .right, size, isLeaf, content ] 
exempts for all { //, tr: C, e: E ] (<<?>).left, (<<?>).right, content(<//, tf» 

BasicGraph: trait 

assumes Equality with [ Node for T ] 

imports Set with [ NodeSet for C, Node for E ], 

Pair with [ Edge for C, Node for Tl, Node for T2 ] 
introduces 

empty: -* Graph 
addNode: Graph, Node -* Graph 
addEdge: Graph, Edge -*■ Graph 
nodes: Graph -* NodeSet 
adj: Node, Graph -* NodeSet 
constrains Graph so that 

Graph generated by [ empty, addNode, addEdge ] 
Graph partitioned by [ nodes, adj ] 
for all [ g: Graph, e: Edge, n, nl: Node ] 
nodes(empty) = {} 

nodes(addNode(g, n)) = insert(nodes(g), n) 
nodes(addEdge(g, e)) = insert(insert(nodes(g), cfirst), csecond) 
adj(n, empty) = {} 
adK«, addNode(g nl)) = adj(/i, g) 
adKn, addEdge(g, e)) = 

if n = (e.first) then insert(adj(/i, g), e.second) else adj(n, g) 
implies converts [ nodes, adj ] 
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Connectivity: trait 

assumes Equality with [ Node for T ], BaskGraph 
introduces 

reach: NodeSet, Graph -♦ NodeSet 
allReach: NodeSet, NodeSet, Graph -♦ Bool 
connected: Graph -♦ Bool 
constrains reach, allReach, connected so that 

for all [ g: Graph, e: Edge, ns, nsl: NodeSet, ru Node ] 
reacbOu, empty) = {} 
reach(/is, addNode(g, n)) = reach(ns, g) 

allReach({}> «* *) 
allReach(insert(na; n), nsl, g) = 
allReach(w; nsl, g)&(nslQ reachtfn}, g)) 
connected(g) = allReach(nodes(g), nodes(g), g) 
implies converts [ allReach, connected ] 

Graph: trait 

assumes Equality with [ Node for T ] 
imports BaskGraph 
includes Connectivity, 

Connectivity with [ stronglyConnected for connected, pathReach for reach, 
allPathReach for allReach ] 
constrains reach, allReach, connected so that 
for all [ g: Graph, e: Edge, nr NodeSet ] 

reacb(/i5, addEdge(g, «)) = nacb(ns, g) U 

(if (*.first) € ns then insert(reach({(e.second)}, g), (csecond)) 
else if (csecond) € ns then insert(reach({(efirst)}, g), (e.first)) 
ebe{}) 
constrains pathReach, allPathReach, stronglyConnected so that 
for all [ g: Graph, e: Edge, its: NodeSet ) 

pathReach(«s; addEdge(g, e)) = pathReach(/w; g) U 
(if (e.first) € ns 

then insert(pathReach({(e.second)}, g), (e.second)) 

elseO) 
implies converts [ reach, allReach, connected, pathReach, allPathReach, 
stronglyConnected ] 
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Rings, Fields, and Numbers 

Ring: trait 

includes AbelianGroup with [ + for O, for unit, - # for inv ], 
Semigroup with [ * for O J, 
Distributive 

RingWithUnit: trait 

includes Ring, Identity with [ * for O, 1 for unit ] 

Infixlnverse: trait 

assumes Inverse 

introduces #0#: T, T — T 

constrains #0# so that for all [ x, y: T ] 

x® y = xO inv(y) 
implies converts [ #0# ] 

Integer: trait 

includes RingWithUnit with [ Int for T ], 
Ordered with [ Int for T ], 

Infixlnverse with [ + for O, - # for inv, - for 0, Int for T ] 
asserts Int generated by [ 1, +, - # ] 
for all [ x- Int ] 

x < (x + 1) 
implies Rational without [ '\ / ] with [ Int for R ] 
converts [ 0, *, #-#, =, ^, >,<,>] 

Field: trait 

includes RingWithUnit 

introduces jT 1 : T — T 

constrains *, ~ l so that for all [ x: T ] 

(x = 0) | ((x^x 1 )) = 1) 
exempts (T 1 

Rational: trait 

includes Field with [ R for T ], 
Ordered with [ R for T ], 

Infixlnverse with [ + for O, - # for inv, - for 0, R for T ], 
Infixlnverse with [ * for O, # _1 for inv, / for 0, R for T ] 
asserts 

R generated by [ 1, +, - #, _1 ] 
for aU [ x y, z: R ] 
0< 1 

((x + z)<{y+ z)) = (x<y) 
(x = 0)\ ((0 < (x 1 )) = (0 < x)) 
implies converts [ 0, *,# — #, /, =,<,>.<»>] 
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Lattices 



ExtremalBound: trait 

assumes PartialOrder 

includes AbelianSemigroup with [ .gib for O ] 

constrains .gib so that for all [ x, y, z: T ] 

(x#by)£x 

((2 £ x) & (z < y))**(z ^ (jc .gib >-)) 

Semilattice: trait 

includes PartiallyOrdered, 

ExtremalBound, 

ExtremalBound with [ > for <, .lub for .gib ] 
introduces _L: -* T 
constrains J. so that for all [ x: T ] 

implies AbelianMonoid with [ J. for unit, .lub for O ] 

Lattice: trait 

includes Semilattice 
introduces T: -* T 
constrains T so that for all [ x: T ] 

x<T 
implies Lattice with [ T for ±, _L for T, .gib for .lub, .lub for .gib, 

>for £, < for >, > for <, < for > ] 
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Enumerated Data Types 

Enumerated: trait 

imports Ordinal 
includes Ordered 
introduces 

first: -♦T 
last: -»T 
succ:T-+ T 
pred: T -* T 
ord: T -* Ord 
asserts T generated by [ first, succ ] 
T partitioned by [ ord ] 
for all [ x. y: T ] 

ord(first) = first 

ord(succ(x)) = if x — last then ord(last) else succ(ord(x)) 
pred(succ(jf)) = if x = last then pred(last) else x 
x<.y= ord(jc) <J ordCy) 
implies T generated by [ last, pred ] 
for all [ x: T ] 

succ(pred(jt)) = if x - first then succ(first) else x 
first <, x 
x < last 
converts [ =, <, >,<•>] 

Rainbow: trait 

includes Enumerated with [ Color for T ] 
introduces 

red: -♦ Color 

orange: -* Color 

yellow: -* Color 

green: -* Color 

blue: -* Color 

violet: -♦ Color 
asserts 

Color generated by [ red, orange, yellow, green, blue, violet ] 

first = red 

last = violet 

succ(red) = orange 

succ(orange) = yellow 

succ(yellow) = green 

succ(green) = blue 

succ(blue) = violet 
implies converts [ pred, last, ord, = , ^, >, <, >, red, orange, yellow, green, blue, 

violet ], 

[ succ, first, ord, =,<»>, <, >, red, orange, yellow, green, blue, violet ] 

Character: trait includes Enumerated with [ Char for T ] 
% For each programming language there will be mappings from character and string constants to 
% terms in the shared language. Because of the variety of character orderings and notations for 
% constants, these definitions are not likely to be portable across programming languages. 
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Display Traits 

% The following traits represent a fairly straightforward translation of the specifications in 

% "Formal Specification as a Design Tool" (CSL-80-1). We have not attempted to improve the 

% design presented there, merely to translate it into Larch. 

Coordinate: trait introduces minus: Coordinate, Coordinate -» Coordinate 
Illumination: trait introduces combine: Illumination, Illumination -* Illumination 
Boundary: trait introduces apply: Boundary, Coordinate -+ Bool 
Transform: trait introduces apply: Transformation, Coordinate -*• Coordinate 
Displayable: trait 

introduces 

appearance: T, Coordinate -* Illumination 
in: T, Coordinate -»• Bool 

Picture: trait 

assumes Boundary, Transform, Illumination, 

Displayable with [ Contents for T ] 
includes Displayable with [ Picture for T ] 

introduces makePkture: Contents, Boundary, Transformation -*> Picture 
constrains Picture so that 

Picture generated by [ makePkture ] 

for all [ en: Contents, b: Boundary, /: Transformation, cd: Coordinate ] 
appearance(makePicture(c/i, b, t), cd) = 

appearance(cn, apply(/, cd)) 
in(makePicture<cR, b, t), cd) = apply(b, cd) 
implies converts [ appearance: Picture, Coordinate -» Illumination, 
in: Picture, Coordinate -+ Bool ] 

Contents: trait 

assumes Coordinate, Illumination, Displayable with [ Component for T ] 

includes Displayable with [ Contents for T ] 

introduces 

empty: -»■ Contents 

addComponent: Contents, Component, Coordinate -» Contents 
constrains Contents so that 

Contents generated by [ empty, addComponent ] 
for all [ en: Contents, cm: Component, cd, cdl: Coordinate ] 
appearance(addComponent(cn, cm, cdl), cd) = 
if in(cm, minus(a£ cdl)) 
then (if in(cn, cd) 

then combine(appearance(cm, minuted, cdl)), 
appearance(c/i, cd)) 
else appearance(cm, minus(c^ cdl))) 
else appearance(cn, cd) 
~in(empty, cd) 

in(addComponent(c/i, cm, cdl), cd) = 
in(cm, minus(cd, cdl)) | in(cn, cd) 
implies converts [ appearance: Contents, Coordinate -*■ Illumination, 

in: Contents, Coordinate -*■ Bool ] 
exempts for all [ cd- Coordinate ] appearance(empty, cd) 
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Component: trait 

assumes Displayable with [ View for T ], 

Displayable with [ Text for T J, 

Displayable with [ Figure for T 1 
includes ComponentCoercion with [ View for T, coerceView for coerce"], 

ComponentCoercion with [ Text for T, coerceText for coerce ], 

ComponentCoercion with [ Figure for T, coerceFigure for coerce ] 

ComponentCoercion: trait 

assumes Displayable 

incudes Displayable with [ Component for T ] 

introduces coerce: T -+ Component 

constrains Component so Oat for all [ t: T, c± Coordinate ] 

appearance(coerce(/), or) = appearance^, cd) 

in(coerce(/), cd) = in(/, cd) 

View: trait 

assumes Displayable with [ Picture for T \, 
Equality with [ Pictureld for T J, 
Container with [ IdList for C, Pictureld for E ], 
Coordinate 
includes Displayable with [ View for T ] 
introduces 

empty: -+ View 

addPicture: View, Coordinate, Pictureld, Picture -*■ View 
findPictures: View, Coordinate -* IdList 
deletePicture: View, Pictureld -* View 
constrams View so that 

View generated by [ empty, addPicture ] 

for all [ v.- View, cd, cdl: Coordinate, id, idl: Pictureld, p: Picture ] 
appearance(addPicture(v, cdl, id p), cd) = 

if in(p, minus(c4 cdl)) then appearance^, minus(c4 cdl)) 
else appearance(v, cd) 
~in(empty, cd) 

in(addPicture(v, cdl, id p), cd) = (info minus(c4 cdl)) | in(v, cd)) 
rIndPictures(empty, cd) - new 
rmdPictures(addPicture(v, cdl, id, p), cd) = 

if va{p, minuted, cdl)) then insert^ findPictures(v, cd)) 
else ftndPictures(v, cd) 
deletePkture(empty, id) = empty 
deletePicture(addPicture(v, cdl, idl, p), id) = 

if id .eq idl thai v ebe addPkture(deletePicture(v, id), cd idl, p) 
implies converts [ findPictures, deletePicture, 

appearance: View, Coordinate -*■ Illumination, 
in: View, Coordinate -+ Bool ] 
exempts for all [ cd- Coordinate ] appearance(empty, cd) 

Display: trait 

assumes Boundary, Transform, Illumination, Coordinate, 

Equality with [ Pictureld for T ], 

Container with [ IdList for C, Pictureld for E ] 
includes Picture, Contents, Component, View 
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